CHIP STATEMENT¶

A chip statement selects for which chips all following compute, label, ignore and set statements are meant. A chip selection remains valid until the next chip statement. Example:

If a chip matches at least one of the chip descriptions, the following configuration lines are examined for it, otherwise they are ignored.

A chip description is built from several elements, separated by dashes. The first element is the chip type, the second element is the name of the bus, and the third element is the hexadecimal address of the chip. Such chip descriptions are printed by sensors(1) as the first line for every chip.

The name of the bus is either isa, pci, virtual, spi-*, i2c-N or mdio with N being a bus number as bound with a bus statement. This list isn't necessarily exhaustive as support for other bus types may be added in the future.

You may substitute the wildcard operator * for every element. Note however that it wouldn't make any sense to specify the address without the bus type, so the address part is plain omitted when the bus type isn't specified. Here is how you would express the following matches:

If several chip statements match a specific chip, they are all considered.

LABEL STATEMENT¶

A label statement describes how a feature should be called. Features without a label statement are just called by their feature name. Applications can use this to label the readings they present. Example:

The first argument is the feature name. The second argument is the feature description.

Note that you must use the raw feature name, which is not necessarily the one displayed by "sensors" by default. Use "sensors -u" to see the raw feature names. Same applies to all other statement types below.

IGNORE STATEMENT¶

An ignore statement is a hint that a specific feature should be ignored - probably because it returns bogus values (for example, because a fan or temperature sensor is not connected). Example:

The only argument is the feature name. Please note that this does not disable anything in the actual sensor chip; it simply hides the feature in question from libsensors users.

COMPUTE STATEMENT¶

A compute statement describes how a feature's raw value should be translated to a real-world value, and how a real-world value should be translated back to a raw value again. This is most useful for voltage sensors, because in general sensor chips have a limited range and voltages outside this range must be divided (using resistors) before they can be monitored. Example:

The example above expresses the fact that the voltage input is divided using two resistors of values 6.8 Ohm and 10 Ohm, respectively. See the VOLTAGE COMPUTATION DETAILS section below for details.

The first argument is the feature name. The second argument is an expression which specifies how a raw value must be translated to a real-world value; `@' stands here for the raw value. This is the formula which will be applied when reading values from the chip. The third argument is an expression that specifies how a real-world value should be translated back to a raw value; `@' stands here for the real-world value. This is the formula which will be applied when writing values to the chip. The two formulas are obviously related, and are separated by a comma.

A compute statement applies to all sub-features of the target feature for which it makes sense. For example, the above example would affect sub-features in3_min and in3_max (which are voltage values) but not in3_alarm (which is a boolean flag.)

The following operators are supported in compute statements:

You may use the name of sub-features in these expressions; current readings are substituted. You should be careful though to avoid circular references.

If at any moment a translation between a raw and a real-world value is called for, but no compute statement applies, a one-on-one translation is used instead.

SET STATEMENT¶

A set statement is used to write a sub-feature value to the chip. Of course not all sub-feature values can be set that way, in particular input values and alarm flags can not. Valid sub-features are usually min/max limits. Example:

The example above basically configures the chip to allow a 5% deviance for the +5V power input.

The first argument is the feature name. The second argument is an expression which determines the written value. If there is an applying compute statement, this value is fed to its third argument to translate it to a raw value.

You may use the name of sub-features in these expressions; current readings are substituted. You should be careful though to avoid circular references.

Please note that set statements are only executed by sensors(1) when you use the -s option. Typical graphical sensors applications do not care about these statements at all.

BUS STATEMENT¶

A bus statement binds the description of an I2C or SMBus adapter to a bus number. This makes it possible to refer to an adapter in the configuration file, independent of the actual correspondence of bus numbers and actual adapters (which may change from moment to moment). Example:

The first argument is the bus number. It is the literal text i2c-, followed by a number. As there is a dash in this argument, it must always be quoted.

The second argument is the adapter name, it must match exactly the adapter name as it appears in /sys/class/i2c-adapter/i2c-*/name. It should always be quoted as well as it will most certainly contain spaces or dashes.

The bus statements may be scattered randomly throughout the configuration file; there is no need to place the bus line before the place where its binding is referred to. Still, as a matter of good style, we suggest you place all bus statements together at the top of your configuration file.

Running sensors --bus-list will generate these lines for you.

In the case where multiple configuration files are used, the scope of each bus statement is the configuration file it was defined in. This makes it possible to have bus statements in all configuration files which will not unexpectedly interfere with each other.

STATEMENT ORDER¶

Statements can go in any order, however it is recommended to put `set fanX_div' statements before `set fanX_min' statements, in case a driver doesn't preserve the fanX_min setting when the fanX_div value is changed. Even if the driver does, it's still better to put the statements in this order to avoid accuracy loss.

THERMAL SENSOR TYPES¶

Available thermal sensor types:

For example, to set temp1 to thermistor type, use:

Only certain chips support thermal sensor type change, and even these usually only support some of the types above. Please refer to the specific driver documentation to find out which types are supported by your chip.

In theory, the BIOS should have configured the sensor types correctly, so you shouldn't have to touch them, but sometimes it isn't the case.

THERMAL HYSTERESIS MECHANISM¶

Many monitoring chips do not handle the high and critical temperature limits as simple limits. Instead, they have two values for each limit, one which triggers an alarm when the temperature rises and another one which clears the alarm when the temperature falls. The latter is typically a few degrees below the former. This mechanism is known as hysteresis.

The reason for implementing things that way is that high temperature alarms typically trigger an action to attempt to cool the system down, either by scaling down the CPU frequency, or by kicking in an extra fan. This should normally let the temperature fall in a timely manner. If this was clearing the alarm immediately, then the system would be back to its original state where the temperature rises and the alarm would immediately trigger again, causing an undesirable tight fan on, fan off loop. The hysteresis mechanism ensures that the system is really cool before the fan stops, so that it will not have to kick in again immediately.

So, in addition to tempX_max, many chips have a tempX_max_hyst sub-feature. Likewise, tempX_crit often comes with tempX_crit_hyst. tempX_emerg_hyst, tempX_min_hyst and tempX_lcrit_hyst exist too but aren't as common. Example:

The hysteresis mechanism can be disabled by giving both limits the same value.

Note that it is strongly recommended to set the hysteresis value after the limit value it relates to in the configuration file. Implementation details on the hardware or driver side may cause unexpected results if the hysteresis value is set first.